\subsection{Numerical grading}

The product owners were asked to grade the requirements with a value from zero to five. A requirement ranked with a zero meant that it was of no importance at all to them. The requirements that got rated a five were of vital importance to the product and were to be treated as mandatory.

\begin{center}
	\begin{tabular}{| l | p{10cm} | }
	  	\hline        
	  0 & Requirement should be discarded.\\
		\hline
	  1 & The customers are not interested in the requirement unless it is almost free to include it.\\
		\hline
	  2 & The customers have some interest in the requirement if including it will be cheap.\\
		\hline
	  3 & Represents a good requirement that the customers want, but not if it interferes with higher rated requirements.\\
		\hline
	  4 & A requirement that is of great value to the customer, but it is not mandatory for the goals to be fulfilled.\\
		\hline
	  5 & Requirement is mandatory.\\
		\hline
	\end{tabular}
\end{center}

The product owners were able to give all requirements the score they wished with no maximum total score to use and there were no comparison between requirements. Therefore the outcome of ranking isn't optimized but gives an early overview of how important all requirements are according to the product owner.
\\\\
The contractors also found a few requirements that could be removed, mainly due to the re-definition of the project mission that made the application company-specific. These were marked as dropped in the requirements specification. Large disagreements between contractors and product owners were handled through negotiations \pageref{negotiation}. The grading the product owners made can be seen below:

\begin{center}
	\begin{tabular}{| p{10cm} | l | }
			\hline  
Alert messages & 5 \\
		  	\hline     
Filter bookmarks & 3 \\
		  	\hline     
Filter open hours & 4 \\
		  	\hline     
Filter radius & 4 \\
		  	\hline     
From specified location & 1 \\
		  	\hline     
Map view directions & 4 \\
		  	\hline     
POI popup & 5 \\
		  	\hline     
Panable map view & 5 \\
		  	\hline     
Scaling map arrow & 2 \\
		  	\hline     
Specifiable location & 2 \\
		  	\hline     
User location & 5 \\
		  	\hline     
Fetch POIs & 5 \\
		  	\hline     
Map arrow shows distance & 2 \\
		  	\hline     
Show POIs & 5 \\
		  	\hline     
Show map & 5 \\
		  	\hline     
Application resume rigidity & 5 \\
		  	\hline     
Error response time & 3 \\
		  	\hline     
Execution rigidity & 5 \\
		  	\hline     
Image resolution & 4 \\
		  	\hline     
Maximum pins & 2 \\
		  	\hline     
Maximum radius & 1 \\
		  	\hline     
Support for Android & 5 \\
		  	\hline     
Support for iOS & 5 \\
		  	\hline     
Open in google maps & 0 \\
		  	\hline     
Remove pin & 0 \\
		  	\hline     
Colour blind friendly & 0 \\
		  	\hline     
Cancelable POI & 0 \\
		  	\hline     
Calendar Event & 0 \\
		  	\hline     
	\end{tabular}
\end{center}

\subsection{100 dollar test}

As to get a stronger test which also includes comparisons, though do not consider consistency, the contractors used the 100 dollar test described by Bjorn Regnell during the sixth lecture of ETS170 2011. As the consistency has been approved by the Focal point prioritization below this test can be considered quite safe.
\\\\
The product owners were allowed to give each non-dropped requirement a prioritization between 0 and 9. Though the sum of all prioritization was not be higher than the amount of requirements multiplied, by the sum of 9 divided by 2 rounded up, which gave us the number 635. This is the final prioritization and can be considered as it has been confirmed by the earlier prioritizations and validation that it's correct. As its correct said prioritization can be found at each requirement.

%695

\subsection{Focal Point}

The contractors also used Focal Point to get a more detailed prioritization of the requirements. The contractors decided to use Focal Point because it gives us a good way of evaluating our requirements using several criteria and then presenting the results in a meaningful way.
\\\\
Focal Point is a tool that utilizes the Analytical Hierarchy Process and pair-wise comparison method. It features an algorithm that reduces the amount of comparisons necessary to get a good result. This means Focal Point is well versed for situations when the amount of requirements is slightly larger.
\\\\
During a scheduled meeting with the product owners the product owners prioritize the requirements based on how useful the requirements would be for the end product. Then the members of the contractors did the same but with a cost approximation as the criteria. By a combination of these two criteria Focal Point was used to analyze the cost to value ratio of all requirements.
\\\\
Seeing as we don't have any limit on the workload for the developers or development time we won't drop any requirements based solely on the results of this prioritization. The contractors do however think that this information will be very useful for the developers when they do the scheduling of releases.
\\\\
The consistency of the Focal Point analysis was in average 98\% which shows that the consistency of the requirement prioritization by the product owners and the contractors were high and can be used without worrying of inconsistent claims.

\newpage
\begin{figure}[h!]
\begin{center}
	\includegraphics[scale= 0.3]{img/prio1.png}
	\caption[]{Distribution of requirements with cost on the X-axis and value on the Y-axis}
\end{center}
\end{figure}
\newpage
\begin{figure}[h!]
\begin{center}
	\includegraphics[scale= 0.3]{img/prio2.png}
	\caption[]{Listing of the requirements with the best ones from a cost/value perspective first}
\end{center}
\end{figure}